Document optimistic locking #10366
Document optimistic locking #10366
Conversation
|
Waiting for team review.... |
|
|
||
| When Optimistic Locking is enabled, each entity gets an additional system attribute with the name `MxObjectVersion` of type `Long`. This field is automatically populated with the correct value. The default value is `1` and this value will be automatically increased with every commit of that entity instance. | ||
|
|
||
| Upon `update` and `delete`, the attribute value is from the object compared to the value available for this record in the database. If it is the same, then the update or delete will proceed. If it is different, which means the object is modified by another party since it is last read, a `ConcurrentModificationRuntimeException` is thrown, preventing the update or delete from proceeding. The `MxObjectVersion` attribute on the Mendix object is not write-protected. Setting this value however will **not** result in this value being saved into the database. Its current value will be used to compare it with the value for the same record in the database. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
|
||
| # Handling optimistic locking errors in Java actions | ||
|
|
||
| In Java actions if an optimistic locking error is detected similar steps described in `Handling Handling optimistic locking errors in Microflows` can be used for retrying. The `com.mendix.systemwideinterfaces.connectionbus.data.ConcurrentModificationRuntimeException` exception will not be the top level exception thrown by Mendix runtime. It will be wrapped in another exception, so the `cause` chain of caught exception should be inspected. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
|
||
| Above error shows that there was a `ConcurrentModificationRuntimeException` during execution of the change action `Change 'MyEntity'` of the microflow `MyFirstModule.MyMicroflow. The object had the id ~3940649673949185` and was of type `MyFirstModule.MyEntity`. | ||
|
|
||
| The only option is refreshing the page which would cause losing all the changes. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
It seems as is this does not work. But if we apply the existing changes on the retrieved object it would work.
emirmx
force-pushed
the
run/4756-document-optimistic-locking
branch
from
0651976 to
4db4e4f
Compare
|
Approved from runtime-core point of view |
|
|
||
| #### Commit Object | ||
|
|
||
| When the `MxObjectVersion` attribute in the object being committed is different from the value in the database, or the object was deleted from the database, the runtime throws a `ConcurrentModificationRuntimeException`. Otherwise, it proceeds with the commit while incrementing `MxObjectVersion` by one. |
There was a problem hiding this comment.
Should we make it more clear that the error is thrown even if the attributes updated are orthogonal (i.e. one person updates AttributeA and the other person updates AttributeB)?
There was a problem hiding this comment.
Could be but I'm not sure if it will have enough benefits :-)
There was a problem hiding this comment.
My thought is that we describe quite clearly that two people can update separate attributes when optimistic locking is turned off. We don't explicitly say that turning it on will prevent this and mean that any change will cause an error, even if it is a different attribute.
But perhaps if people are turning on optimistic locking they will be clear on this without us telling them?
3 participants
No description provided.